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Abstract 

We  introduce  a  tool  we  are  developing  that  will  allow 
designers  of  trusted  applications  to  isolate  those  portions  of 
a  system  where  an  information  flow  policy  is  being  violated. 
The  tool  is  a  language-sensitive  editor  that  checks  a 
program  for  policy  violations  incrementally  as  the  program 
is  developed.  What  is  novel  about  our  approach  is  that  the 
checking  occurs  as  a  form  of  type  checking. 

1.  Introduction 

Mandatory  access  control  policies  are  concerned  with  the 
authorizations  of  individuals  to  access  information  based  on 
its  sensitivity.  Within  the  context  of  automated  information 
systems,  each  access  by  a  subject  to  an  object  is  mediated 
based  on  Txed  labels  associated  with  both.  In  general, 
applications  will  be  executed  by  single-level  subjects.  If 
viewed  from  the  perspective  of  the  Bell  and  LaPadula 
model  [2],  a  single-level  subject  will  be  constrained  by  the 
simple  security  property  and  the  *-property  such  that  it  can 
neither  obtain  read  access  to  objects  which  it  does  not 
dominate  nor  gain  write  access  to  objects  which  do  not 
dominate  it,  respectively.  Most  applications,  e.g.  word 
processing  systems,  software  engineering  utilities,  etc.,  can 
be  executed  by  single-level  subjects;  in  fact,  careful 
application  design  can  permit  even  complex  multilevel  data 
structures  to  be  managed  by  single-level  subjects  [11]. 

There  are,  however,  situations  in  which  it  is  useful  to 
have  applications  which  are  designed  to  violate  the  rules  of 
a  system’s  security  policy  enforcement  mechanism,  but 
which  are  trusted  to  do  so  only  in  a  manner  commensurate 
with  externally-established  authorizations.  For  example,  in 
the  case  of  the  *-property  of  the  Bell  and  LaPadula  model 
[2],  the  application  would  be  designed  so  that,  when 
executed  by  a  subject  with  a  range  of  access  classes,  viz.  a 
multilevel  subject,  the  subject  could  read  from  an  object 
with  a  high  access  class  label  and  write  to  an  object  with  a 
lower  one.  The  multilevel  subject  will  be  constrained  by  the 
underlying  mandatory  policy,  enforced  through 
comparisons  with  the  class  deTning  the  upper  bound  of  its 
range  on  read  accesses  and  by  the  lower  bound  of  its  range 
for  write  accesses. 

Trusted  applications  are  speciTcally  designed  to  be 


executed  by  multilevel  subjects  and  are  part  of  a  system’s 
trusted  computing  base  (TCB).  Careful  security 
engineering  of  the  combined  trusted  application  and  TCB 
will  provide  measurable  assurance  that  the  trusted 
application  will  behave  as  speciTed  and  that  its  potential  to 
violate  security  policy  in  an  arbitrary  and  perhaps  malicious 
manner  is  not  realized.  Unfortunately,  current  practice  in 
the  development  of  large  systems  does  not  always  treat  the 
engineering  of  the  code  to  be  executed  by  multilevel 
subjects  with  adequate  rigor.  Hence  an  environment  ripe  for 
the  insertion  and  exploitation  of  malicious  software  exists. 
This  makes  certiTcation,  software  maintenance,  and 
continued  accreditation  difTcult.  This  paper  reports 
ongoing  research  to  develop  a  new  tool  to  support  the 
development  of  large  trusted  applications. 

Powerful  formal  systems  for  reasoning  about  security 
have  been  studied  [3] [  10] .  Given  their  expressiveness,  and 
that  often  useful  proof  methodologies  are  missing,  these 
systems  have  not  been  widely  adopted  in  practice.  We 
believe  that  this  is  because  the  methods  offer,  at  most, 
formal  systems  to  reason  about  security  properties; 
typically  there  is  no  automated  support  for  practitioners. 
However,  reasoning  about  whether  programs  violate 
mandatory  access  control  (MAC)  policies,  such  as 
articulated  in  the  Bell  and  LaPadula  model  [2],  does  not 
require  such  power.  This  was  observed  by  Dorothy  Denning 
in  her  seminal  work  on  secure  information  tow  in  computer 
systems.  She  described  a  way  that  compilers  could 
efTciently  check  programs  for  secure  implicit  and  explicit 
information  tow  [5],  [6].  Unfortunately,  this  work  was 
never  widely  used  in  practice,  according  to  Denning  [8], 

2.  An  Editor  for  Trusted  Applications 

We  are  developing  a  new  framework  to  carry  out  an 
extension  of  the  analysis  envisioned  by  Denning.  The 
framework  is  a  formal  system  of  simple  rules  with  which 
one  can  make  judgements  about  information  tow  in 
programs.  What  is  interesting  is  that  these  rules  follow 
rather  directly  from  a  type  system  for  a  polymorphic 
programming  language  with  subtypes.  Many  such  systems 
have  been  proposed  [9]  [14]  [15]. 

So  the  technical  basis  for  the  tool  described  in  this  paper 
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is  actually  an  advanced  type  system,  speciTcally,  one 
supporting  polymorphism  and  subtypes.  There  is  a  natural 
correspondence  between  information  tow  analysis  and  type 
checking.  Ordinary  types  like  int  and  real,  for  instance, 
can  be  replaced  by  security  classes  like  L  (low)  and  H 
(high).  Further,  just  as  int  is  a  subtype  of  real  in  a 
traditional  language,  we  can  regard  L  as  a  subtype  of  H, 
rejecting  the  fact  that  information  tow  from  L  to  H  is 
permitted.  A  type  system  that  supports  polymorphism  with 
respect  to  types  therefore  supports  polymorphism  with 
respect  to  security  classes.  Such  a  system  affords  us  an 
opportunity  to  accurately  capture  information  tow  in 
procedures  that  accept  inputs  of  arbitrary  security  classes,  a 
source  of  difTculty  in  Denning’s  original  approach. 

We  are  developing  an  algorithm  for  deciding  whether  a 
given  program  has  a  type  in  our  type  system.  This  amounts 
to  the  algorithm  having  to  Tnd  a  type  derivation  for  the 
program,  using  the  rules  of  the  type  system.  If  a  derivation 
cannot  be  found,  then,  since  the  rules  characterize  secure 
information  tow  ,  the  algorithm  reports  that  the  program  has 
an  illicit  tow  with  respect  to  a  given  tow  policy  .  If  a 
derivation  can  be  found,  then  the  algorithm  reports  that  the 
program  is  secure  by  inferring  a  type  for  the  program.  The 
type  reveals  any  tow  assumptions,  as  subtype  constraints, 
that  are  needed  in  the  derivation. 

We  intend  to  implement  the  complete  algorithm  as  a 
language-sensitive  editor  for  a  traditional  block-structured 
language.  This  kind  of  editor  is  smart  in  that  as  a  program  is 
edited,  it  can  be  analyzed  behind  the  scenes  so  that  a 
programmer  receives  immediate  feedback.  The  editor  is 
said  to  be  language  sensitive  because  these  analyses  may 
determine  whether  a  program  satisTes  certain  restrictions  of 
the  language  and,  in  some  cases,  even  correct  it  if  it  fails  to 
do  so.  We  describe  below  a  prototype  language-sensitive 
editor  that  we  are  building  for  a  subset  of  the  full  type 
system  for  secure  information  tow .  It  illustrates  some 
important  features  of  the  algorithm  we  have  developed  thus 
far.  We  give  editor  snapshots  that  show  how  the  editor 
responds  to  certain  inputs  during  the  course  of  writing  some 
sample  programs. 

3.  Sample  Applications  Using  the  Editor 

Before  showing  how  the  editor  behaves,  we  must  Trst 
describe  briety  some  technical  details  of  the  type  system  on 
which  the  editor  is  based. 

We  take  as  our  types  the  security  classes  U,  C,  S,  and  '/'.S', 
ordered  according  to  the  following  subtype  relation: 

t/c  c  c  s  c  TS. 

Intuitively,  what  this  means  is  that  U  is  a  subtype  of  TS 
since  tows  from  U  to  TS  are  permitted.  These  types  form 


the  primitive  or  base  types  of  the  system  and  may  vary  from 
one  tow  policy  to  another  .  There  is  a  form  of  type  in  the 
system  called  a  type  scheme  and  it  has  the  form 

V  a1 , ...  ,  an  with  k.  x 

The  variables  aj,...  an  are  called  type  variables  and  are 
universally  quantised.  For  our  purpose,  they  can  be 
assumed  to  range  over  the  primitive  types.  The  set  k  is  a  set 
of  subtype  constraints ,  expressed  at  the  level  of  type 
variables  and  primitive  types.  For  example,  a  C  U  is  a 
constraint  that  conveys  a  is  a  subtype  of  U.  The  symbol  x 
stands  for  a  data  type,  which  for  our  purpose,  will  consist 
only  of  a  mapping  type  written  Xj  — *  x2.  An  object  of  this 
type  is  a  procedure  that  maps  elements  of  type  x1  to 
elements  of  type  x2. 

In  our  examples,  we  use  operations  from  a  hypothetical 
trusted  computing  base,  or  TCB.  Among  these  are 
operations  for  opening  Ties,  for  reading  ( ropen )  and  writing 
( wopen ),  and  I/O  (get  and  put).  Ropen  expects  a  subject’s 
read  class  (rc)  and  a  Tie  to  be  opened  and  ensures  that  the 
read  class  dominates  the  access  class  of  the  Tie.  On  the 
other  hand,  given  a  subject’s  write  class  (wc)  and  a  Tie  to  be 
opened,  wopen  ensures  that  the  access  class  of  the  Tie 
dominates  the  write  class. 

We  adopt  get  and  put  as  our  input  and  output  operations; 
get  (i)  returns  the  next  element  of  the  input  Tie  descriptor  i, 
and  put  (v,  o )  writes  value  v  to  the  output  Tie  descriptor  o. 
Each  of  these  operations  has  a  type  built  into  the  editor.  For 
example,  put  expects  to  be  called  with  a  value  classiTed  at 
some  level,  say  (3,  and  a  Tie  descriptor  classiTed  at  least  as 
high,  say  6,  and  writes  the  value  to  the  Tie.  This  is  conveyed 
by  the  type  scheme 

V  (3,  6  with  (3  C  5.  (3  ->  5  ->  unit 

Here  the  type  unit  indicates  that  put  is  executed  only  for  its 
effect  and  does  not  return  a  result.  The  subtype  constraint 
ensures  the  *-property.  Consequently,  among  the  allowable 
types  for  put  is 

C  — >  S  -*  unit 

since  C  QS,  but  not 

S  — >  C  — *  unit 

because  S  is  not  a  subtype  of  C.  Notice  that  with  put  typed 
as  above,  we  protect  it  against  being  called  to  write  down 
for  a  multilevel  subject. 

We  now  give  three  sample  programs  to  illustrate  the 
editor.  Each  is  intended  to  be  executed  by  multilevel 
subjects.  Our  Trst  example  is  a  secure  procedure  to  copy  a 
Tie.  It  copies  the  elements  of  a  Tie  with  some  security  class 


to  another  Tie  whose  security  class  is  at  least  as  high.  We 
will  show  how  the  editor  we  are  developing  can  reveal  an 
attempt  to  tamper  with  the  procedure  so  that  it  also  copies 
the  input  Tie  to  an  unclassiTed  third  Tie. 

Our  second  example  shows  that  there  may  be  times  when 
the  editor  will  prohibit  some  code  satisfying  a  certain 
speciTcation  from  being  written.  The  code  must  therefore 
be  veriTed  within  a  more  expressive  logic.  The  editor  can 
greatly  reduce  the  amount  of  code  that  needs  to  be  veriTed 
in  this  way. 

Finally,  we  illustrate  the  behavior  of  the  editor  when 
writing  a  procedure  that  downgrades  information.  In  this 
case,  the  editor  deems  the  function  insecure.  If,  in  fact,  it  is 
an  authorized  downgrade,  then  the  function  would  have  to 
be  veriTed  in  some  other  logic  as  above. 


File  Edit  View  Tools  Options  Structure  Text  Hel| 


_ ■ _ 

<exp> 

:  V  a  .  a 

■ 

Context:  expList 

■ 

Figure  1.  Initial  editor  window 


3.0.1  Secure  file  copy:  The  copy  procedure  has  four 
parameters  rc,  wc,  /,  and  g;  rc  and  wc  are  the  read/write 
classes  of  a  multilevel  subject, /is  the  Tie  to  be  copied  and 
g  is  the  result.  Using  the  editor,  we  begin  with  the  initial 
window  in  Figure  1.  Here  <exp>  is  a  placeholder.  All 
placeholders  are  delimited  by  angle  brackets. 

At  each  stage,  the  editor  infers  a  type  (security 
classiTcation)  for  the  program  and  displays  it  below  the 
program.  At  this  point,  the  editor  reports  that  the  type  of  the 
copy  procedure  is  V  a. a  because  it  knows  nothing  about  its 
deTnition  as  yet;  it  is  only  a  placeholder  thus  far. 

When  the  user  selects  <exp>  with  the  mouse,  a  menu  of 
choices  for  the  various  kinds  of  expressions  appears  at  the 
bottom  of  the  window.  These  choices  permit  the  user  to 
elaborate  the  expression.  A  sample  of  the  selections  and 
their  results  is  given  in  Table  1.  One  of  the  choices,  fun,  is 
a  function.  Selecting  it  gives  us  a  placeholder  for  a  function 
of  one  argument,  as  shown  in  the  window  of  Figure  2. 


Table  1:  Sample  Editor  Selections 


Selection 

Result 

Type 

fun 

X  <id>  <exp> 

Va.V|la^|5 

while 

while  <exp>  do 
<exp> 

end 

unit 

J 

<exp> ;  <exp> 

Va  .  a 

II 

<exp>  II  <exp> 

bool 

let 

let  <id>  =  <exp>  in 
<exp>  end 

vp.p 

letvar 

letvar  <id>  :=  <exp>  in 
<exp>  end 

Vy  -y 
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A  <identifier> .  <exp> 

:  V  x,  5.  x  — >  8 


Context:  exp  apply  fun  if  while  let 

letvar  ;  set!  :=  ~  &&  II  o  +  - 
<<=>>=  ::  (,) 


Figure  2.  Editor  window  after  choosing  fun 

The  editor  now  infers  a  mapping  type  for  the  program  but 
it  still  knows  nothing  as  yet  about  the  relationship  between 
x  and  8.  Next  we  Til  in  the  identiTer  placeholder  with  rc,  a 
subject’s  read  class,  and  select  another  function  for  the 
expression  placeholder,  giving  the  window  in  Figure  3. 

Now  we  get  a  type  that  looks  more  like  the  Tnal  type  of 
the  copy  routine,  but  without  more  of  the  deTnition 
available,  nothing  more  can  be  inferred  about  its  type.  We 
now  complete  the  deTnition  using  operations  from  the 
TCB,  giving  the  program  in  Figure  4. 

The  type  inferred  for  the  program  now  has  three  subtype 
constraints. 


y£x,  8£jt,  yCjt 


Figure  3.  Editor  window  after  supplying  rc 
and  selecting  fun  again 


File  Edit  View  Tools  Options  Structure  Text  Help 


Figure  4.  Editor  window  upon  completion  of 
secure  copy  procedure 


Type  variable  x  is  the  type  of  rc  and  corresponds  to  the  read 
class  of  the  subject,  5  is  the  type  of  wc  and  corresponds  to 
the  subject’s  write  class,  y  is  the  access  class  of/,  and  jr  the 
access  class  of  g.  The  type  indicates  that  the  copy  routine  is 
capable  of  copying  a  Tie/,  classiTed  at  level y,  to  a  Tie  g  at 
an  equal  or  higher  level  ji  (y  C  jt)  as  long  as  the  read  class 
of  the  subject  dominates  /  (y  C  x)  and  its  write  class  is 
dominated  by  g  (6  £  jt),  which  is  what  we  want.  The  editor 
allows  a  user  to  build  a  program  while  simultaneously 


inferring  types  at  each  step. 

Now  suppose  we  try  to  tamper  with  the  procedure  by  also 
copying/to  an  unclassiTed  Tie  OUTPUT _U .  We  insert  the 
declaration  wopenfwc,  OUTPUT JJ)  and  the  statement 
put(v,  h)  in  the  loop  body.  The  result  is  shown  in  Figure  5. 
Notice  what  happened  to  the  inferred  type.  It  indicates  that 
the  procedure  is  not  as  general  as  one  might  have  thought. 
SpeciTcally,  it  can  copy  only  unclassiTed  Ties: 

V  x,  Jt.  t  — »■  U  — >  t/  — >  Jt  — >  unit 

If  invoked  to  copy  any  Tie  except  an  unclassiTed  one,  it  will 
raise  an  exception.  In  contrast,  the  type  of  the  original  Tie- 
copy  procedure  indicates  that  it  is  able  to  copy  Ties 
classiTed  at  any  level.  The  fact  that  the  type  of  the  modiTed 
procedure  does  not  reject  this  desired  property  is  an 
indication  that  the  procedure  is  suspicious. 


File  Edit  View  Tools  Options  Structure  Text  Help 


krc.  kwc.kf.  kg. 

let  i  =  ropen  (rc ,  f)  in 
let  o  =  wopen  (wc,  g)  in 
let  h  =  wopen  (wc,  OUTPUT _U)  in 
letvar  v  :=  get  (i)  in 
while  v  !=  EOF  do 
put  (v,  o)  ; 
put  (v,h)\ 
v  :=  get(i) 

end 

:  »!/— »C/— »ji— »  unit 


Context:  exp  e<exp>  <exp>  e  fun  fix  if  while 
let<idxexp>e  let<id>e<exp>  letvar<idxexp>e 
letvar<id>e<exp>  e;<exp>  <exp>;e 

Figure  5.  Rogue  copy  procedure 

Consider  what  would  happen  if  we  tried  to  execute  the 
rogue  procedure  without  Trst  subjecting  it  to  our  type 
(security)  analysis.  When  called  by  a  multilevel  subject,  say 
with  write  class  unclassiTed  and  read  class  secret,  and  a  Tie 
/  at  secret,  the  procedure  will  write  a  secret  value  to  the 
unclassiTed  Tie  OUTPUT _U .  Opening  OUTPUT _U  will 
succeed  because  the  subject  has  write  class  of  unclassiTed. 
Unfortunately  this  is  the  state  of  affairs  in  practice  today. 
Many  programs  are  being  used  by  multilevel  subjects  and 
they  could  very  well  be  programs  like  this  rogue  procedure 


doing  something  undesirable  without  users  ever  knowing  it. 
When  our  system  is  used  to  develop  code,  however,  it  alerts 
one  to  rogue  programs  like  this  one. 

3.0.2  A  guard:  Observe  that  in  the  rogue  Tie  copy 
example,  the  editor  did  not  detect  a  policy  violation  in  the 
procedure.  It  merely  concluded  that  the  rogue  procedure 
can  be  used  to  copy  only  unclassiTed  Ties  if  policy  is  not  to 
be  violated.  To  rid  ourselves  of  this  restriction,  we  can 
simply  delete  the  offending  put  statement  to  restore  the 
generality  of  Tie  copy.  In  some  cases,  generality  cannot  be 
restored  so  easily. 


Figure  6.  Guard  procedure 


As  an  example,  consider  a  guard.  Here  we  assume  the 
precise  deTnition  of  a  guard  as  described  by  Schell, 
reported  by  Denning  [7],  and  described  by  Schell  and 
Brinkley  [  13].  It  has  to  partition  the  elements  of  a  multilevel 
stream  according  to  their  security  classes.  Its  operations  are 
based  upon  credible  access  labels  which  are  attributes  of  the 
stream  elements  and  may  be  certiTed  to  be  in  compliance 
with  security  policy.  A  guard  is  deTned  in  Figure  6.  Here/ 


is  a  multilevel  stream  and  the  Ties  opened  for  reading  and 
writing  have  the  classiTcations  suggested  by  their  names. 
The  type  inferred  for  the  guard  implies  that  the  guard  can  be 
called  only  with  a  single-level  input  stream  consisting 
exclusively  of  unclassiTed  values: 

V  x.  x  — >  U  —■ *  U  unit 

But  a  guard  cannot  be  limited  this  way,  so  in  order  to 
recover  its  full  generality,  it  must  be  developed  outside  of 
the  editor  and  veriTed  some  other  way.  The  editor  is  useful 
in  such  situations  because  it  helps  to  identify  system 
components  where  more  complex  forms  of  analysis  are 
needed.  This  greatly  reduces  the  amount  of  code  that  has  to 
be  veriTed  by  more  complex  techniques.  In  our  system,  the 
guard  would  have  to  be  separately  veriTed  outside  the 
editor  and  re-introduced  into  the  system  by  supplying  an 
appropriate  typing  for  it,  say, 

V  x  ,  y  with  yCx.  r -*■  U  y  -*■  unit 

Here  x  corresponds  to  the  read  class,  rc,  of  the  subject,  U  to 
the  subject’s  write  class,  wc,  and  y  to  the  access  class  of  the 
Tie  representing  the  multilevel  input  stream.  This  would 
permit  the  guard  to  be  called  with  multilevel  input  streams. 
An  exception  would  still  be  raised,  though,  if  it  were  called 
by  a  subject  whose  read  class  is  lower  than  some  element  in 
the  stream,  or  whose  write  class  is  not  unclassiTed. 


Figure  7.  Downgrade  procedure 


3.0.3  A  downgrader:  Sometimes  the  editor  will  detect  a 
tow  policy  violation  which  may  be  authorized.  This  is  the 


case  for  the  downgrading  procedure  illustrated  in  Figure  7. 
Here,  the  input  and  output  Ties  are  hard-coded.  (Note  that  a 
more  general  downgrading  function  might  permit  the  input 
and  output  Ties  to  be  function  parameters,  in  which  case  the 
results  would  parallel  those  of  the  guard.)  Writing  from  a 
high  input  to  a  low  output  violates  the  type  inference  rules 
and  no  type  results,  as  indicated  by  (?).  As  in  the  case  of  the 
guard,  the  editor  has  identiTed  code  for  which  further 
analysis  is  needed,  ideally,  such  code  should  be  isolated  in 
its  own  domain  to  be  executed  by  multilevel  subjects,  while 
the  remainder  of  the  application  can  be  executed  by  single- 
level  subjects. 

4.  Summary 

In  this  paper,  we  have  presented  ongoing  work  to 
develop  a  practical  tool  to  assist  the  developers  of  trusted 
applications.  Our  tool  does  not  take  the  place  of  the  careful 
design  and  analysis  that  should  be  applied  to  the 
development  of  TCB  software,  however,  it  does  permit 
software  developers  to  isolate  code  which  violates  policy 
from  that  which  is  benign.  We  anticipate  that  the  editor 
could  be  employed  in  the  development  of  very  large 
software  applications  and  that,  as  is  the  case  with  all  other 
tools  used  in  the  development  of  trusted  systems,  the  editor 
would  be  maintained  under  a  life-cycle  assurance  program 
commensurate  with  the  target  evaluation  class  of  the 
intended  trusted  application.  Software  certiTed  by  the  editor 
provides  an  additional  level  of  conTdence  that  the  security 
policy  will  not  be  violated.  This  can  be  especially  important 
in  environments  where  the  same  code  is  executed  by  both 
single-level  and  multilevel  subjects. 

Currently,  the  editor  implements  only  that  part  of  the  type 
system  that  guarantees  programs  do  not  violate  explicit 
information  tow  policy .  We  plan  to  extend  the  system  to 
handle  what  Denning  calls  implicit  information  tows  as 
well.  This  will  address  legitimate  channels  by  which 
processes  can  transmit  information  between  security  classes 
[12].  Some  progress  has  been  made  in  this  regard.  However, 
covert  channels  will  not  be  considered.  Finally,  in  some 
cases,  the  system  may  claim  there  is  a  violation  when  really 
there  is  not.  This  is  also  true  of  Denning’s  system  [6]  and  is 
a  consequence  of  the  unsolvability  of  deciding  security. 
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